feat: index each language separately, and assert it stays that way - #447

Split out of #447, which verified it. This is the half that can land
now; the nightly pin and the smoke assertion that goes with it stay
there, since they need each other and both wait on a formal SifterSearch
release.

## The bug

Pagefind names each language's index in one JSON map in
`pagefind-entry.json` and writes that map in whatever order it iterated,
which is not the same order twice. Two bakes of one source then produce
two spellings of the same fact — identical index hashes and page counts,
different language order:

```
< {"languages":{"ko":{"hash":"ko_72ba3bbda7",…},"en":{"hash":"en_e66da688eb",…},"km":{…}},…}
> {"languages":{"en":{"hash":"en_e66da688eb",…},"ko":{"hash":"ko_72ba3bbda7",…},"km":{…}},…}
```

**This site does not show it yet.** Every page is indexed as the wiki's
content language today, so there is one language and no order to get
wrong. It appears the moment translations are indexed in their own,
which is what chaotic-ground/SifterSearch#69 does — a bake against that
build holds three (en 39, ko 19, km 1) and #411's two-bake check fails
on this one file, in the root bundle and in both skin copies of it.

## Why it lands before the pin moves

So the bump that brings the language fix in just passes. Otherwise that
PR fails the reproducibility check for a reason that has nothing to do
with what it changed, and whoever opens it — updatecli, most likely —
gets to work out why.

## Where the fix belongs

Reproducibility is this build's promise (#411), not the indexer's, so
the build keeps it. That is the same work `StripBuildStamps` already
does for the per-request ids MediaWiki leaves in a page: something
upstream writes a value that varies per build, and the build settles it.

Key order carries no meaning in JSON and the client looks a language up
by name, so sorting the map changes nothing any reader of the bundle can
tell.

`Build::stabilizeSearchIndex()` runs in the orchestrator, after the
index job `runJobs()` holds back to the end and before the skin passes,
so the one bundle they all copy is already settled — nothing to do per
pass.

## What the re-encode is careful about

It does not try to reproduce Pagefind's bytes, only the same bytes every
time, which is all the promise asks — so a change in Pagefind's own
formatting cannot quietly break this. The flags keep it close anyway, so
a diff against an older bake stays readable; escaping the
`include_characters` list to `‿` would make the file differ for no
reason, which is the very thing being fixed.

An entry file that cannot be parsed, or that holds no language map, is
returned as `null` and left exactly as Pagefind wrote it. A bundle this
does not understand is not one to rewrite.

## Tests

`Search::stableIndexEntry()` is pure, so `SearchTest` covers it
directly. The fixtures are the real two files, off one runner, from one
source — and the test asserts they differ before asserting they
normalise to the same thing, so it cannot pass vacuously.

`typos` reads the `ba` in a Pagefind hash (`ko_72ba3bbda7`) as a
misspelling of `by`, so `.typos.toml` learns their shape, beside the
entry already there for Translate's own hex stamps.

## Verification

Proven in CI on #447, which pins the nightly carrying SifterSearch#69:
the bake produced `en`, `ko` and `km` indexes, and **the two bakes came
out identical** — the step that failed before this fix.

On this branch, with the pin still at `v0.7.1`, the change is a no-op in
effect: one language, nothing to reorder.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01NiyBN88bnGhcXVUXkpD7Mc)_

Co-authored-by: Claude <noreply@anthropic.com>